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ISHM capability includes: detection of anomalies, diagnosis of causes of anomalies, 
prediction of future anomalies, and user interfaces that enable integrated awareness (past, 
present, and future) by users. This is achieved by focused management of data, 
information and knowledge (DIaK) that will likely be distributed across networks. 
Management of DIaK implies storage, sharing (timely availability), maintaining, 
evolving, and processing. Processing of DIaK encapsulates strategies, methodologies, 
algorithms, etc. focused on achieving high ISHM Functional Capability Level (FCL). 
High FCL means a high degree of success in detecting anomalies, diagnosing causes, 
predicting future anomalies, and enabling health integrated awareness by the user. A 
model that enables ISHM capability, and hence, DIaK management, is denominated the 
ISHM Model of the System (IMS). 

We describe aspects of the IMS that focus on processing of DIaK. Strategies, 
methodologies, and algorithms require proper context. We describe an approach to define 
and use contexts, implementation in an object-oriented software environment (G2), and 
validation using actual test data from a methane thruster test program at NASA SSC. 
Context is linked to existence of relationships among elements of a system. For example, 
the context to use a strategy to detect leak is to identify closed subsystems (e.g. bounded 
by closed valves and by tanks) that include pressure sensors, and check if the pressure is 
changing. We call these subsystems “Pressurizable Subsystems.” If pressure changes are 
detected, then all members of the closed subsystem become suspect of leakage. In this 
case, the context is defined by identifying a subsystem that is suitable for applying a 
strategy. Contexts are defined in many ways. Often, a context is defined by relationships 
of function (e.g. liquid flow, maintaining pressure, etc.), form (e.g. part of the same 
component, connected to other components, etc.), or space (e.g. physically close, 
touching the same common element, etc.). The context might be defined dynamically (if 
conditions for the context appear and disappear dynamically) or statically. Although this 
approach is akin to case-based reasoning, we are implementing it using a software 
environment that embodies tools to define and manage relationships (of any nature) 
among objects in a very intuitive manner. 

Context for higher level inferences (that use detected anomalies or events), 
primarily for diagnosis and prognosis, are related to causal relationships. This is useful to 
develop root-cause analysis trees showing an event linked to its possible causes and 
effects. The innovation pertaining to RCA trees encompasses use of previously defined 
subsystems as well as individual elements in the tree. This approach allows more 
powerful implementations of RCA capability in object-oriented environments. For 
example, if a pressurizable subsystem is leaking, its root-cause representation within an 
RCA tree will show that the cause is that all elements of that subsystem are suspect of 



leak. Such a tree would apply to all instances of leak-events detected and all elements in 
all pressurizable subsystems in the system. 

Example subsystems in our environment to build IMS include: Pressurizable 
Subsystem, Fluid-Fill Subsystem, Flow-Thru -Valve Subsystem, and Fluid Supply 
Subsystem. 

The software environment for IMS is designed to potentially allow definition of 
any relationship suitable to create a context to achieve ISHM capability. 



